1. Field
Embodiments relate to parallel processes for performing multiple incremental copies.
2. Background
Computing systems often include one or more host computers (“hosts”) for processing data and running application programs, direct access storage devices (DASDs) for storing data, and a storage controller for controlling the transfer of data between the hosts and the DASD. Storage controllers, also referred to as control units or storage directors, manage access to a storage space comprised of numerous hard disk drives connected in a loop architecture, otherwise referred to as a Direct Access Storage Device (DASD), and other storage devices. Hosts may communicate Input/Output (I/O) requests to the storage space through the storage controller.
In many systems, data on one storage device, such as a DASD, may be copied to the same or another storage device so that access to data volumes can be provided from two different devices. A point-in-time copy involves physically copying all the data from source volumes to target volumes so that the target volume has a copy of the data as of a point-in-time. A point-in-time copy can also be made by logically making a copy of the data and then only copying data over when necessary, in effect deferring the physical copying. This logical copy operation is performed to minimize the time during which the target and source volumes are inaccessible.
A number of direct access storage device (DASD) subsystems are capable of performing “instant virtual copy” operations, also referred to as “fast replicate functions.” Instant virtual copy operations work by modifying metadata such as relationship tables or pointers to treat a source data object as both the original and copy. In response to a copy request from a host, the storage subsystem substantially immediately reports creation of the copy without having made any physical copy of the data. Only a “virtual” copy is created, and the absence of an additional physical copy is completely unknown to the host.
Later, when the storage system receives updates to the original or copy, the updates are stored separately and cross-referenced to the updated data object. At this point, the original and copy data objects may begin to diverge. The initial benefit is that the instant virtual copy occurs almost instantaneously, completing much faster than a normal physical copy operation. This frees the host and storage subsystem to perform other tasks. The host or storage subsystem may proceed to create an actual, physical copy of the original data object during background processing, or at another time.
One such instant virtual copy operation is known as a FLASHCOPY® operation. (FLASHCOPY is a registered trademark or common law mark of International Business Machines Corporation in the United States and/or other countries.) A FLASHCOPY® operation involves establishing a logical point-in-time relationship between source and target volumes on the same or different devices. The FLASHCOPY® operation guarantees that until a track in a FLASHCOPY® relationship has been hardened to its location on the target disk, the track resides on the source disk. A relationship table is used to maintain information on all existing FLASHCOPY® relationships in the subsystem. During the establish phase of a FLASHCOPY® relationship, one entry is recorded in the source and target relationship tables for the source and target that participate in the FLASHCOPY® being established. Each added entry maintains all the required information concerning the FLASHCOPY® relationship. Both entries for the relationship are removed from the relationship tables when all FLASHCOPY® tracks from the source extent have been physically copied to the target extents or when a withdraw command is received. In certain cases, even though all tracks have been copied from the source extent to the target extent, the relationship persists.
A target bitmap identifies which tracks involved in the FLASHCOPY® relationship have not yet been copied over and are thus protected tracks. Each track in the target device is represented by one bit in the bitmap. The target bit is set when the corresponding track is established as a target track of a FLASHCOPY® relationship. The target bit is reset when the corresponding track has been copied from the source location and destaged to the target device due to writes on the source or the target device, or a background copy task.
In certain mechanisms, as part of the establishment of the logical point-in-time relationship during the FLASHCOPY® operation, all tracks in the source cache that are included in the FLASHCOPY® relationship are destaged to the physical source volume, e.g., source DASD, and all tracks in the target cache not included in the FLASHCOPY® must be discarded.
Once the logical relationship is established, hosts may then have immediate access to data on the source and target volumes, and the data may be copied as part of a background operation. A read to a track that is a target in a FLASHCOPY® relationship and not in cache triggers a stage intercept, which causes the source track corresponding to the requested target track to be staged to the target cache when the source track has not yet been copied over and before access is provided to the track from the target cache. This ensures that the target has the copy from the source that existed at the point-in-time of the FLASHCOPY® operation. Further, any destages to tracks on the source device that have not been copied over triggers a destage intercept, which causes the tracks on the source device to be copied to the target device.
Instant virtual copy techniques have been developed, at least in part, to quickly create a duplicate copy of data without interrupting or slowing foreground processes. Instant virtual copy techniques, such as a FLASHCOPY® operation, provide a point-in-time copy tool. Instant virtual copy techniques may be used for a variety of applications, including, for example, data backup, data migration, data mining, testing, etc. For example, an instant virtual copy technique may be used for the creation of a physical “backup” copy of the source data, to aid in disaster recovery.
Thus, an instant virtual copy may be described as an instant snapshot of a data set or volume. There is a source volume and a target volume. The target volume is an instant snapshot of the source volume. Any changes to the source volume after the instant virtual copy has been established are not copied to the target.
An incremental virtual copy (e.g., an incremental FLASHCOPY®) is an enhancement of an instant virtual copy. The incremental virtual copy creates multiple snapshots over a period of time using the same source volume and target volume. It should be noted that incremental copy may include not only virtual copies but may also include physical copies if background copy is selected, i.e., an incremental copy may include both an incremental virtual copy and/or an incremental physical copy.
In an incremental copy, the first flash of a source volume to a target volume is usually done with background copy. When the background copy finishes, data has been copied from the source volume to the target volume. After the first incremental copy is established, there may be subsequent flashes or increments between the same source volume and target volume. Subsequent flashes or increments copy modified tracks from the source volume to the target volume since the last flash or increment.
The incremental copy has two additional bitmaps: 1) a Change Recording (CR) bitmap on the source volume and 2) a Change Recording (CR) bitmap on the target volume. The source CR bitmap has a bit for every track on the source volume. When there is a write on a track of the source volume after the incremental copy has been established, then a bit is set in the source CR bitmap to indicate that the track needs to be copied in the subsequent flash or increment. If there is a write on the target volume after the establish, then a bit is set in the target CR bitmap to indicate that the track needs to be copied in the subsequent flash or increment. On a subsequent flash or increment, the source and target CR bitmaps are merged into the target bitmap to indicate the tracks that need to be copied from the source volume.
In certain mechanisms, the incremental copy has a CR bitmap on a source volume for every incremental copy. So, if there are N incremental copy targets, then N source CR bitmaps are kept on the source volume.
Incremental copy provides the capability to refresh a volume in a FLASHCOPY® relationship and reduce background copy time when only a subset of data has changed. The main idea of incremental copy is maintaining a CR bitmap for every incremental relationship. Any writes to customer tracks on a source or a target volume will be remembered by the CR bitmap. This bitmap may be used later to indicate which tracks need to be recopy from source to target at next refresh.
In certain mechanisms, the function of incremental copy maintains a change recording bitmap on both source and target volume and support only one incremental copy relationship for a volume. In order to support more than one incremental relationship, a volume may require multiple change recording bitmaps. Increasing the number change recording bitmaps on a volume has several disadvantages: (a) Such a design does not scale well when many incremental relationships are required; (b) Change recording bitmaps cannot be attained dynamically and may have to be reserved in metadata and may require code changes; (c) Reserving change recording bitmaps wastes metadata space if a customer does not use incremental copy. Only source volumes may use more than one CR bitmap. That means that more than one change recording bitmap on a target volume is unnecessary; (d) Maintaining and managing multiple change recording bitmaps on the same volume increases the complexity of code.
An alternative approach in which instead maintaining the change recording bitmap on both source and target volumes, a change recording bitmap is maintained on target volume only. Any writes to customer tracks on both source and target volumes may be remembered by the change recording bitmap on the target volume.
If a source volume has multiple incremental targets, writes to source tracks may be remembered by all change recording bitmaps on those incremental target volumes. This approach allows users to avoid the complicated maintenance of multiple change recording bitmaps on the same volume. Since any incremental target volume can be in only one relationship, only one change recording bitmap is needed on incremental target volume.
Therefore, these mechanisms avoid having a change recording structure on the source storage. In such mechanisms in which there is a change recording structure at a target only, the source directly updates the target change recording structure, and the target change recording structure controls the copying from the source to the target. Such mechanisms have one target change recording structure for an incremental copy on the copy target.